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ABSTRACT 


This  report  documents  a  solution  to  the  limited  size  o£ 
the  permanent  file  base  on  the  Control  Data  Corporation 
(CDC)  ccMiiputers  running  the  NOS/BE  operating  system.  The 
CDC  permanent  file  concept,  and  modifications  made  to  the 
standard  operating  system  are  explained.  These  modifica¬ 
tions  have  increased  the  number  of  permanent  files  allowed 
for  the  default  permanent  file  set,  and  also  improved  the 
response  time  for  all  permanent  file  functions. 


ADMINISTRATIVE  INFORMATION 


The  work  described  in  this  report  was  performed  in  the 
Systems  Software  Group  (Code  1892.3)  of  the  Computation, 
Mathematics,  and  Logistics  Department,  David  W.  Taylor  Naval 
Ship  Research  and  Development  Center  (DTNSRDC)  under  the 
sponsorship  of  the  DTNSRDC  Computer  Center  (Code  189) . 


INTRODUCTION 


Two  files  are  used  for  referencing  permanent  file  names 
and  locations  on  disk.  The  Permanent  File  Directory  (PFD) 
is  a  fixed  length  file  that  contains  a  fixed  length  entry 
for  each  permanent  file/ID  pair  in  the  system.  The  PFD  file 
is  divided  into  subdirectories,  so  the  entire  PFD  need  not 
be  searched  to  find  a  desired  permanent  file.  Each  file  in 
the  system  "belongs”  to  a  particular  subdirectory  based  upon 
a  hashing  algorithm.  Standard  NOS/BE  uses  nine  characters 
of  the  user  ID  as  a  hashing  algorithm.  At  DTNSRDC  we  use 
nine  characters  of  the  permanent  file  name.  The  PFD  con¬ 
tains  a  pointer  to  the  Permanent  Pile  Catalog  (PPC) .  The 
PFC  is  a  fixed  length  file  with  variable  length  entries  that 
contain  actual  disk  locations  of  files. 


When  a  particular  file  is  needed  by  a  user,  the  per¬ 
manent  file  routine  finds  the  file  by  hashing  to  the  begin¬ 
ning  of  the  subdirectory  the  file  resides  in,  then  searches 
the  PFD  sequentially  from  this  point.  When  the  file's  PFD 
entry  is  found,  the  PFC  pointer  is  determined,  and  the  per¬ 
manent  file  routine  reads  the  PFC  entry  to  find  the  file's 
disk  location. 


The  size  of  the  PFD  is  determined  by  the  number  of 
files  defined  at  initialization.  This  number  cannot  exceed 
16384  (decimal) .  The  number  of  files  also  determines  the 
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number  of  subdirectories  and  size  of  the  subdirectories. 
When  all  entries  in  a  subdirectory  are  in  use,  the  next  file 
to  hash  to  that  subdirectory  will  use  the  next  empty  entry 
in  the  PFD,  which  is  really  in  another  subdirectory.  This 
is  a  condition  called  overflow.  Thus,  an  overflowed  sub¬ 
directory  uses  entries  in  other  subsequent  subdirectories. 
This  overflowed  subdirectory  is  full,  and  there  is  no  room 
for  entries  that  belong  there.  In  time,  the  hashing  algo¬ 
rithm  to  find  files  in  the  PFD  is  useless  because  the  entire 
directory  is  being  searched  due  to  overflow. 


OBJECTIVES 


The  objective  of  this  project  was  to  increase  the  PFD 
size  to  allow  more  than  16000  permanent  file  PFD  entries  and 
to  eliminate  subdirectory  overflow,  while  keeping  any 
changes  transparent  to  the  computer  user.  A  minimum  amount 
of  code  changes  was  desirable  to  facilitate  upgrading  to 
newer  levels  of  the  operating  system. 


SOLUTION 


One  solution  to  the  directory  problems  considered  but 
rejected  was  increasing  the  maximum  size  of  the  directory. 
This  was  rejected  due  to  the  extensive  modifications 
required  to  the  permanent  file  PP  routines,  which  have  a 
limited  amount  of  space  available. 


Another  rejected  solution  was  using  more  than  one  dev¬ 
ice  set  for  default  permanent  files.  Since  files  are  writ¬ 
ten  to  disk  before  being  cataloged,  this  approach  would 
necessitate  knowing  the  correct  device  set  residence  of  a 
file  before  the  file  was  opened.  This  would  require  control 
card  changes  which  would  not  be  transparent  to  the  user,  or 
would  necessitate  copying  a  file  created  on  the  "wrong"  set 
to  another  set  to  maintain  its  proper  residence. 


The  solution  chosen  to  solve  our  problems  was  to  create 
multiple  PFD/PFC  files  called  Multiple  Directories  (MD)  for 
the  permanent  file  default  set.  Each  MD  is  on  a  separate 
disk  pack.  User  files  are  distributed  among  the  MD^’s  by 
hashing  of  the  user  Identification  (ID) .  Thus,  the  direc¬ 
tory  entries  for  all  files  of  a  particular  ID  reside  on  the 
same  MD. 
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In  tb*  ND  set  we  aaintain  one  eet  of  disks,  but  use 
■ore  than  one  directory  to  locate  the  files  stored  on  these 
disks.  Up  to  ten  directories  can  be  defined,  effectively 
increasing  the  nuaber  of  PFD  entries  to  160,000  entries. 


MD  CONFIGURATION  MODIFICATIONS 


A  device  set  is  a  group  of  rotating  mass  storage  (RMS) 
devices.  In  the  standard  device  set,  there  is  a  master  dev¬ 
ice  that  contains  the  PFD/PFC  files  and  related  device  set 
tables,  and  a  variable  number  of  member  RMS  devices  (See 
figure  1) .  In  the  multiple  PFD/PFC  device  set  the  secondary 
directory  PFD/PFC  files  reside  on  set  member  RMS  devices 
(See  figure  2) .  A  separate  RMS  device  is  required  for  each 


PF  SET  ORGANIZATION 
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Member 

Member 

PFD 

PFC 

FIGURE  1 


PF  SET  ORGANIZATION  WITH  MULTIPLE  DIRECTORY 
MD  «1  MD  «2 

Master  Member  Member  Member 
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directory  defined.  The  number  of  multiple  directories  in 
use  is  defined  in  comdeck  IPARAMS,  with  the  symbol  IP. NMD 
equated  to  the  number  required.  The  default  for  IP. NMD  is 
one.  In  comdeck  PPSYS,  word  72B  (P.NMD)  in  central  memory 
is  defined  as  the  pointer  to  the  number  of  MDs  defined. 


Separate  device  sets  for  system  files,  queue  files, 
scratch  files,  and  permanent  files  can  be  defined  in  the 
Central  Memory  Resident  (CMR)  routine.  The  pointers  to  each 
directory  for  these  sets  are  maintained  in  the  Mounted  Set 
Table  (MST)  in  CMR.  Every  configured  set  has  an  entry  in 
the  MST  (See  figure  3) . 


Mounted  Set  Table  (MST) 
Standard  Device  Set  Configuration 


MST  tl 

MST  «2 

MST  «3 

System 

Set 

Perm.  File 
Set 

Queue 

Set 

FIGURE  3 


For  a  multiple  directory  set,  each  MD  has  a  separate 
MST  entry  (See  figure  4).  Only  the  default  permanent  file 
set  may  have  multiple  directories  defined.  When  configuring 
a  MD  set,  all  multiple  directories  must  be  in  succession, 
with  no  other  intervening  sets  defined  in  the  Equipment 
Status  Table  (EST) .  Figure  5  illustrates  an  illegal  confi¬ 
guration.  The  Queue  Set  MST  is  between  the  Permanent  File 
Set  Multiple  Directory  MSTs.  IP. NMD  is  checked  against  the 
EST  configuration  to  ensure  the  proper  number  of  MD's  are 
configured.  The  first  six  characters  of  each  MD  setname 
configured  must  be  identical.  The  seventh  character  is  used 
to  uniquely  identify  the  secondary  MD^s  (i.e.,  SN^SYSSET  for 
MDtl,  SN-SYSSETl  for  MD«2,  up  to  SN>SYSSET9  for  MD«10) 

On  a  multi-mainframe  system  that  shares  default  per¬ 
manent  files,  a  separate  RMS  controller  is  required  for  each 
multiple  directory  defined.  Inter-locked  stack  requests  are 
used  to  prevent  simultaneous  mainframe  directory  access. 
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Mounted  Set  Table  (MST) 
Device  Set  Configuration  with  MD 
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FIGURE  4 


Mounted  Set  Table  (MST) 

ILLEGAL  Device  Set  Configuration  with  MD 
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FIGURE  5 


MD  DEADSTART  MODIFICATIONS 


When  initializing  a  configured  multiple  directory  set, 
each  M)  must  be  initialized.  (Type  “SYSSETrl'*  and 
“SYSSETlrl'  for  a  two  MD  system  at  deadstart  equipment 
change  time.)  GENDJ  has  been  modified  to  generate  ADDSET 
control  cards  to  add  each  MD  as  a  separate  master r  and  also 
as  a  member  of  the  permanent  file  default  set.  For  initial¬ 
ization  of  an  M),  ADDSET (ADS)  creates  the  PFD/PFC  flies  and 
pack  label  on  the  MD  device  as  a  master r  and  then  adds  the 
device  as  a  member  of  the  default  permanent  file  set.  GENDJ 
then  notifies  the  operator  when  deadstart  is  complete.  A 
normal  deadstart  is  then  required  for  system  operation. 


All  subsequent  deadstarts,  normal  or  recovery  type,  are 
unchanged.  At  deads tart  time  RECOVER  and  TMT  validate  all 
PPD/PPC  files  for  the  multiple  directories  and  build  a  Dev¬ 
ice  Allocation  Map  (DAM)  table  which  contains  the  free  and 
available  space  for  each  member  of  the  set.  This  table  is 
then  written  to  the  master  device  of  the  default  permanent 
file  set,  which  is  MD#1.  TMT  checks  the  current  configura¬ 
tion  for  the  number  of  multiple  directories  configured,  and 
then  rewrites  P.NMD  with  this  value.  Mount  (MNT) ,  at  dead- 
start  time,  runs  in  a  Master/Member  mode  on  the  secondary 
multiple  directories,  mounting  them  as  separate  masters, 
creating  an  MST  entry  for  each  MD  which  contains  the 
pointers  to  the  PPD/PPC  files,  and  also  mounting  them  as 
members  of  the  default  permanent  file  set. 


MD  OPERATION  MODIFICATIONS 


On  our  standard  operating  system  we  have  incorporated 
some  modifications  to  improve  permanent  file  efficiency. 
The  multiple  directory  set  requires  some  of  these  changes. 
Permanent  files  on  the  PF  default  set  are  hashed  by  per¬ 
manent  file  name  (rather  than  ID)  to  a  subdirectory  in  the 
PFD.  This  was  done  to  prevent  subdirectory  overflow, 
because  the  ID  name  assignment  used  at  DTNSRDC  does  not  pro¬ 
vide  a  good  file  distribution.  A  user's  private  device  set 
is  still  hashed  by  ID  name.  On  a  rename  of  a  file  by  per¬ 
manent  file  name,  we  modified  PFR  to  move  the  PFD  entry  if 
the. renamed  file  hashed  to  a  different  subdirectory.  The 
standard  NOS/BE  system  does  not  move  the  directory  entry, 
even  when  a  rename  results  in  the  file  belonging  to  a  dif¬ 
ferent  subdirectory. 


In  the  multiple  directory  PF  set  the  permanent  files 
are  hashed  by  ID  name  to  the  proper  directory,  then  to  the 
subdirectory  by  permanent  file  name.  The  number  of  multiple 
directories  in  use  is  defined  in  a  central  memory  word  in 
low  core  (P.NMD) .  The  hash  routine  uses  this  value  for  the 
number  of  hash  points  to  find  a  file's  proper  directory. 
The  directory  number  is  then  biased  by  the  default  permanent 
file  set  MST  ordinal  to  obtain  the  multiple  directory  MST 
ordinal  for  the  file.  Routines  using  hash  code  do  not 
require  re-assembly  for  different  system  configurations. 
These  hashing  modifications  are  in  comdeck  PFHASH,  which  is 
used  by  attach(PFA),  catalog (PFC) ,  load(LPF),  extend(EPF), 
and  rename (PFR). 


I 


The  RENAME  control  card  is  the  only  control  card  with 
changes  visible  to  the  user.  Since  a  rename  by  ID  might 
require  moving  PFD  and  PFC  entries  to  a  new  MD,  rename  by  ID 
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was  not  allowed.  A  procedure  was  created  for  users  to 
rename  a  file's  ID.  This  procedure  copies  the  file,  re¬ 
catalogs  the  file  with  the  new  ID,  and  purges  the  entry  for 
the  old  ID. 


The  AUDIT  program  used  by  DTNSRDC  is  locally  written. 
It  reads  the  PPD/PFC  files  directly.  With  a  multiple  direc¬ 
tory  set,  AUDIT  need  access  only  one  of  the  PFD/PFC  files 
when  performing  an  audit  by  ID.  This  means  that  with  a  two 
MD  system,  AUDIT  need  search  through  only  approximately 
one-half  the  permanent  file  base.  On  a  full  system  audit 
all  multiple  directories  are  processed  but  separate  PFD/PFC 
statistics  are  provided.  A  system  audit  may  also  be  done  on 
individual  multiple  directories  by  specifying  the  MD  setname 
on  the  AUDIT  control  card. 


The  DUMPF  utility,  used  for  dumping  permanent  files, 
was  modified  to  process  all  directories  with  one  DUMPF  con¬ 
trol  card.  Individual  multiple  directories  may  also  be 
dumped  separately  by  specifying  the  MD  setname  on  the  DUMPF 
control  card.  This  individual  directory  dump  feature  halved 
the  time  required  to  do  a  full  permanent  file  dump  on  our 
6600/6700  multi-mainframe  system. 


The  TRANSPF  utility,  used  for  changing  file  residence 
when  removing  a  set  member  device,  was  modified  to  process 
all  MDs  within  the  permanent  file  default  set.  The  FS  and 
TS  parameters  must  be  the  master  multiple  directory (MD#1) , 
and  the  FM  parameter  cannot  be  an  MD. 


DELSET (DLM) ,  used  to  delete  a  member  from  a  set,  was 
modified  to  check  all  MDs  for  permanent  file  residence  on 
the  device  to  be  deleted,  and  also  disallow  a  MD  delete. 

RELABEL,  used  for  adding  flaws  to  a  device  or  writing  a 
new  label,  was  modified  to  add  flaws  to  an  MD  device  as  a 
member  of  the  default  PF  set,  and  not  rewrite  the  MD  device 
label. 


SETNAME  and  REQUEST  control  cards  specifying  a  particu¬ 
lar  MD  other  than  MD#1  (i.e.  -  ' SETNAME, S YSSET 1. '  or 
'REQUEST, LFN, *PF, SN«SYSSET2. ') ,  use  the  default  permanent 
file  set  master  (MD#1) .  MD#i  contains  the  DAM,  Set  Member 
Table  (SMT) ,  and  flaw  tables  for  the  MD  device  set.  When  RB 
file  space  is  needed  or  when  a  file  overflows  a  RMS  device, 
MD#1  device  set  tables  are  used  to  allocate  mass  storage 
space. 
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MD  INSTALLATION  AT  DTNSRDC 


The  CDC  6400  at  DTNSRDC  was  the  first  system  to  use 
multiple  directories.  A  two  MD  set  was  defined  for  this 
system  March  3,  1982.  On  April  4,  1982  the  same  configura¬ 
tion  was  installed  on  the  CYBER74.  The  CDC  6600  and  CDC 
6700  share  permanent  files,  and  a  two  MD  set  was  installed 
on  these  mainframes  August  19,  1982.  The  multiple  directory 
code  was  written  and  installed  on  all  mainframes  at  Level 
508  release  of  the  NOS/BE  operating  system.  Subsequently, 
all  systems  were  up-graded  to  the  Level  552  release  of 
NOS/BE.  Multiple  directory  code  was  enhanced  and  up-graded 
at  the  same  time  the  system  was  up-graded  to  Level  552. 
This  installation  was  complete  on  October  25,  1982. 


When  DTNSRDC  acquired  a  CDC  CYBER  170-176,  NOS/BE  Level 
552  with  MD  code  was  installed  on  this  system.  It  became 
operational  June  13,1983. 


The  CDC  6600/6700  systems  were  retired  and  replaced  by 
the  CDC  CYBER  170-750  system  in  December,  1983.  Level  552 
NOS/BE  and  MD  code  were  installed  and  operational  on  this 
system  December  9,  1983. 


MD  installation  involved  changes  to  32 
with  approximately  2100  lines  of  modified 
6) . 


system  routines 
code  (See  figure 
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The  CDC  6600/6700  shared  permanent  file  base  had  the 
serious  problems  that  multiple  directory  was  designed  to 
solve.  The  PFD  size  limit  had  been  reached,  and  in  the 
ideal  case,  15  of  61  subdirectories  had  overflowed  (See  fig¬ 
ure  7).  The  ideal  case  occurs  immediately  following  reload¬ 
ing  of  the  complete  permanent  file  base,  which  is  rarely 
done.  Since  overflow  of  one  subdirectory  adversely  affects 
the  following  subdirectory,  the  actual  case  was  much  worse. 
He  had  58  of  61  subdirectories  overflowed  with  little  space 


in  the  remaining  ones. 


With  a  two  MO  permanent  file  set,  there  are  no  overflow 
problems,  and  the  number  of  available  PFD  entries  has  dou¬ 
bled  (See  figure  8).  The  batch  and  interactive  response 
times  to  permanent  file  commands  has  significantly  improved 
(See  figures  9  and  10) .  With  the  improved  permanent  file 
function  time,  faster  dump,  audit,  and  load  time,  and  an 
increase  in  allowable  Permanent  File  Directory  entries, 
there  has  been  an  overall  improvement  in  the  CDC  NOS/BE  sys¬ 
tems  performance. 


66/6700  PERNAMEMT  FILE  BASE 


Number  of  directories  ■  1  Number  of  sub-directories  *  61 


subd 

number 

number 
of  PFs 

overflow 

subd 

number 

number 
of  PFs 

overflow 

1 

ld7 

no 

31 

yes 

2 

187 

no 

32 

229 

no 

3 

241 

no 

33 

300 

yes 

4 

213 

no 

34 

296 

yes 

5 

279 

yes 

35 

227 

no 

6 

205 

no 

36 

257 

yes 

7 

197 

no 

37 

245 

no 

8 

241 

no 

38 

289 

yes 

9 

217 

no 

39 

230 

no 

10 

233 

no 

40 

341 

yes 

11 

229 

no 

41 

259 

yes 

12 

333 

yes 

42 

232 

no 

13 

242 

no 

43 

240 

no 

14 

214 

no 

44 

226 

no 

15 

243 

no 

45 

200 

no 

16 

214 

no 

46 

246 

no 

17 

250 

no 

47 

234 

no 

18 

218 

no 

48 

203 

no 

19 

214 

no 

49 

211 

no 

20 

229 

no 

50 

282 

yes 

21 

251 

no 

51 

191 

no 

22 

235 

no 

52 

201 

no 

23 

203 

no 

53 

219 

no 

24 

244 

no 

54 

209 

no 

25 

287 

yes 

55 

245 

no 

26 

269 

yes 

56 

200 

no 

27 

276 

yes 

57 

239 

no 

28 

260 

yes 

58 

292 

yes 

29 

247 

no 

59 

210 

no 

30 

240 

no 

60 

178 

no 

61 

230 

no 

Total  number  of  PFD  entries  ■  14570 
Overflowed  sub-directories  *  15 


FIGURE  7 
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66/6700  PERMANENT  FILE  BASE 

Number  of  directories  ■  2  Number  of  sub-directories  »  si 


subd  number  number 
number  of  PFs  of  PFs 
dirll  dir«2 

overflow  subd  number  number 
number  of  PFs  of  PFs 
dirll  dir#2 

overflow 

1 

72 

115 

no 

31 

124 

158 

no 

2 

93 

94 

no 

32 

121 

108 

no 

3 

111 

130 

no 

33 

180 

120 

no 

4 

103 

110 

no 

34 

135 

161 

no 

5 

117 

162 

no 

35 

108 

119 

no 

6 

86 

119 

no 

36 

112 

145 

no 

7 

86 

111 

no 

37 

107 

138 

no 

8 

121 

120 

no 

38 

135 

154 

no 

9 

94 

123 

no 

39 

105 

125 

no 

10 

117 

116 

no 

40 

230 

111 

no 

11 

95 

134 

no 

41 

125 

134 

no 

12 

169 

164 

no 

42 

136 

96 

no 

13 

110 

132 

no 

43 

126 

114 

no 

14 

95 

148 

no 

44 

103 

123 

no 

15 

106 

137 

no 

45 

100 

100 

no 

16 

102 

112 

no 

46 

123 

123 

no 

17 

133 

117 

no 

47 

99 

135 

no 

18 

114 

104 

no 

48 

94 

109 

no 

19 

110 

104 

no 

49 

94 

117 

no 

20 

111 

118 

no 

50 

139 

143 

no 

21 

109 

142 

no 

51 

77 

114 

no 

22 

120 

115 

no 

52 

94 

107 

no 

23 

105 

98 

no 

53 

100 

119 

no 

24 

119 

125 

no 

54 

100 

109 

no 

25 

130 

157 

no 

55 

129 

116 

no 

26 

104 

165 

no 

56 

93 

107 

no 

27 

143 

133 

no 

57 

98 

141 

no 

28 

125 

135 

no 

58 

161 

131 

no 

29 

127 

120 

no 

59 

126 

84 

no 

30 

119 

121 

no 

60 

100 

78 

no 

61 

102 

128 

no 

Total  number  of  PFD  entries  for  MD  #  1  »  7022 
Total  number  of  PFD  entries  for  MD  #  2  «  7548 
Overflowed  sub-directories  «  o 


FIGURE  8 


PP  FUNCTION  COMPLETION  RATES  (PRIME  TIME) 


MPA  MPB 


Average 

Completion  Time 
in  Seconds 


Average 

Completion  Time 
in  Seconds 


PF  Before  After  Improvement  Before  After  Improvement 
Function  MD  MD  MD  MD 


PF  COMMANDS  COMPLETED  WITHIN  1  SECOND  (PRIME  TIME) 


Percent  Completed  Percent  Completed 

Within  1  Second  Within  1  Second 


PP  Before  ATter  Improvement  Before  After  Improvement 
Function  MD  MD  MD  MD 


VAJ.TU7I 


Catalog 

Purge 


33.0  69.9 

75.1  89.8 


+36.9% 

+14.7% 


22.1  54.9 

65.5  90.2 


f:r; 


+32.8% 

+24.7% 


FIGURE  10 


INITIAL  DISTRIBUTION 


Copies 

12  DIRECTOR 

Defense  Technical  Information  Center  (DTIC) 


CENTER  DISTRIBUTION 


Copies 


1 

18/1809 

GLEISSNER,  G.  H. 

2 

1808 

WILDY,  D. 

1 

189 

GRAY,  G. 

1 

189.1 

HIBBERT,  D. 

1 

189.2 

HAYDEN,  H. 

1 

1892.1 

STRICKLAND,  J. 

1 

1892.2 

SOMMER,  D. 

10 

1892.3 

YEARICK,  R. 

1 

1894 

SEALS,  W. 

1 

1896 

GLOVER,  A. 

1 

522.1 

LIBRARY,  CARDEROCK 

1 

522.2 

LIBRARY,  ANNAPOLIS 

1 

93 

PATENT  COUNSEL 

OTNSRDC  ISSUES  THREE  TYPES  OF  REPORTS 


1.  OTNSRDC  REPORTS,  A  FORMAL  SERIES.  CONTAIN  INFORMATION  OF  PERMANENT  TECH¬ 
NICAL  VALUE.  THEY  CARRY  A  CONSECUTIVE  NUMERICAL  IDENTIFICATION  REGARDLESS  OF 
THEIR  CLASSIFICATION  OR  THE  ORIGINATING  DEPARTMENT. 

2.  DEPARTMENTAL  REPORTS.  A  SEMIFORMAL  SERIES.  CONTAIN  INFORMATION  OF  A  PRELIM¬ 
INARY,  TEMPORARY.  OR  PROPRIETARY  NATURE  OR  OF  LIMITED  INTEREST  OR  SIGNIFICANCE. 
THEY  CARRY  A  DEPARTMENTAL  ALPHANUMERICAL  IDENTIFICATION. 

3.  TECHNICAL  MEMORANDA.  AN  INFORMAL  SERIES,  CONTAIN  TECHNICAL  DOCUMENTATION 
OF  LIMITED  USE  AND  INTEREST.  THEY  ARE  PRIMARILY  WORKING  PAPERS  INTENDED  FOR  IN¬ 
TERNAL  USE.  THEY  CARRY  AN  IDENTIFYING  NUMBER  WHICH  INDICATES  THEIR  TYPE  AND  THE 
NUMERICAL  CODE  OF  THE  ORIGINATING  DEPARTMENT.  ANY  DISTRIBUTION  OUTSIDE  DTNSRDC 
MUST  BE  APPROVED  BY  THE  HEAD  OF  THE  ORIGINATING  DEPARTMENT  ON  A  CASE-BY4:ASE 
BASIS. 


